Refactor CI to produce 64-bit integer interface wheels for WoA#199
Refactor CI to produce 64-bit integer interface wheels for WoA#199mattip merged 1 commit intoMacPython:mainfrom
Conversation
|
Hi @mattip and @matthew-brett , This updated WoA CI script now also generates the 64-bit integer interface wheel, which we can use to build NumPy for Windows-on-ARM. |
| strategy: | ||
| matrix: | ||
| include: | ||
| - INTERFACE64: 1 |
There was a problem hiding this comment.
Is anyone using 32-but builds of Python for Windows on ARM?
If so, I guess we do need the INTERFACE64=0; BUILD_BITS=32 option. But I guess we also need an INTERFACE64=0; BUILD_BITS=64 option, for people building Numpy or Scipy with 32-bit interfaces, but 64-bit builds.
There was a problem hiding this comment.
No, 32-bit Python for Windows on ARM is not a thing, there's only win_arm64.
We do need LP64 (scipy-openblas32 ) and ILP64 (scipy-openblas64) wheels though, that's orthogonal to interpreter bitness.
There was a problem hiding this comment.
If so, I guess we do need the
INTERFACE64=0; BUILD_BITS=32option. But I guess we also need anINTERFACE64=0; BUILD_BITS=64option, for people building Numpy or Scipy with 32-bit interfaces, but 64-bit builds.
Maybe I was incorrect here - but my comment was meant to say that we do not want or need a INTERFACE64=0; BUILD_BITS=32 build - as we have here, but we do want and need an INTERFACE64=0; BUILD_BITS=64 option, that I think we do not have.
There was a problem hiding this comment.
Maybe the matrix/environment variables needs improvement. Both wheels can be imported by 64-bit python win-arm64.
The "32-bit" build uses INTERFACE64: 0, BUILD_BITS: 32. It prints Building for 64-bit binary, 32-bit interface at the beginning of thebuild step, and later prints out Compiling a 64-bit binary
There was a problem hiding this comment.
Hi @matthew-brett,
Just to clarify:
-
In our workflow,
BUILD_BITSdoes not refer to the binary architecture — it always builds 64-bit binaries for WoA. Instead,BUILD_BITSmaps to the integer interface width used by OpenBLAS: -
INTERFACE64=0 → 32-bit integer interface → BUILD_BITS=32 → scipy_openblas32
-
INTERFACE64=1 → 64-bit integer interface → BUILD_BITS=64 → scipy_openblas64
So we already have both:
- INTERFACE64=0; BUILD_BITS=32 (LP64)
- INTERFACE64=1; BUILD_BITS=64 (ILP64)
We use the BUILD_BITS variable purely as a naming and testing label — as seen here in the CI script:
windows-arm.yml#L76-L80
There was a problem hiding this comment.
Shouldn't we then remove BUILD_BITS on the basis that it's confusing, and have some variable like INTERFACE_BITS set internally to 32 for INTERFACE64=0 etc?
|
Thanks @Harishmcw. Once the wheels are uploaded to PyPI we can consider using scipy-openblas64 in NumPy. |
|
I uploaded the 64-bit wheel. The next step is a PR to numpy/numpy to redo the win-arm64 wheel build to use it (simplifying the logic in |
4 participants
This PR refactors the CI workflow to use a matrix strategy for building both 32-bit and 64-bit integer interface wheels for Windows-on-ARM (WoA).
Simplifies the workflow and avoids code duplication.
Ensures both 32-bit and 64-bit integer interface wheels are produced for WoA.
I updated the version in pyproject.toml and made sure it matches
git describe --tags --abbrev=8in OpenBLAS at theOPENBLAS_COMMIT